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ABSTRACT 

Although the security properties of 3G and 4G mobile net¬ 
works have signihcantly improved by comparison with 2G 
(GSM), signihcant shortcomings remain with respect to user 
privacy. A number of possible modihcations to 2G, 3G and 
4G protocols have been proposed designed to provide greater 
user privacy; however, they all require significant modifi¬ 
cations to existing deployed infrastructures, which are al¬ 
most certainly impractical to achieve in practice. In this 
article we propose an approach which does not require any 
changes to the existing deployed network infrastructures or 
mobile devices, but offers improved user identity protection 
over the air interface. The proposed scheme makes use of 
multiple IMSIs for an individual USIM to offer a degree of 
pseudonymity for a user. The only changes required are to 
the operation of the authentication centre in the home net¬ 
work and to the USIM, and the scheme could be deployed 
immediately since it is completely transparent to the exist¬ 
ing mobile telephony infrastructure. We present two dif¬ 
ferent approaches to the use and management of multiple 
IMSIs. 

Categories and Subject Descriptors 

[Networks]: Network properties - network security - mobile 
and wireless security and network privacy and anonymity 

General Terms 

Security 

Keywords 

User privacy threats, anonymity, multiple IMSIs USIM, mo¬ 
bile telephony 

1. INTRODUCTION 

While the first generation (IG) mobile telephony systems 
did not provide any security features, security has been an 
integral part of such systems since the second generation 


(2G). For example, GSM, perhaps the best known 2G sys¬ 
tem, provides a range of security features, including authen¬ 
tication of the mobile to the network, data conhdentiality 
across the air interface, and a degree of user pseudonymity 
through the use of temporary identities. Third and fourth 
generation (3G and 4G) systems, such as UMTS/3GPP and 
Long-Term Evolution (LTE), have enhanced these security 
features, notably by providing mutual authentication be¬ 
tween network and phone, and integrity protection for sig¬ 
nalling commands sent across the air interface. However, 
user privacy protection has remained largely unchanged, re¬ 
lying in all cases on the use of temporary identities |161126| , 
and it has long been known that the existing measures do 
not provide complete protection for the user identity mus]. 
The discussion below applies equally to 2G, 3G and 4G sys¬ 
tems, although we use 3G terminology throughout. 


In mobile telephony, each User Subscriber Identity Module 
(USIM) has a unique International Mobile Subscriber Iden¬ 
tity (IMSI). If the IMSI is sent in cleartext across the air 
interface, and the mapping to the phone user is known by 
an adversary, then a particular user could be tracked us¬ 
ing the IMSI, since it is fixed for the lifetime of the USIM. 
To avoid this major privacy weakness, the visited network 
assigns the phone a Temporary Mobile Subscriber Identity 
(TMSI), which is used for addressing purposes across the air 
interface, and which changes frequently. Of course, if an ad¬ 
versary could link a TMSI to the IMSI then this would rep¬ 
resent a breach of user privacy. Unfortunately, as discussed 
in section [3] below, it is necessary to send the IMSI across 
the air interface in certain circumstances |22| . e.g. when reg¬ 
istering with the network after switching on a phone. 


This user privacy issue has been discussed extensively in the 
literature [3 El El [201 [21] Ezl I28 |. and many modihcations 
to existing protocols have been proposed to avoid the prob¬ 
lem El El in [28]. All these proposals involve making major 
modihcations to the air interface protocol, which would re¬ 
quire changes to the operation of all the serving networks as 
well as all the deployed phones. It seems likely that mak¬ 
ing the necessary major modihcations to the operation of 
the air interface after deployment is essentially infeasible. 
Many of the proposed schemes also involve the use of public 
key cryptography El El [28], which has a high computational 
cost, although there do exist schemes which only use sym- 


metric cryptography m- It would therefore be extremely 
valuable if a scheme offering greater user privacy could be 
devised which did not involve making significant changes to 
the existing mobile telecommunications infrastructures, and 
had minimal computational cost. This motivates the work 
described in this paper. 

The remainder of the paper is structured as follows. In sec¬ 
tion [2] the key terminology and features related to mobile 
telephony systems are briefly reviewed. Privacy terminology 
and the threats to mobile user privacy in existing networks 
are then summarised in section [S] In section |4] our threat 
model is presented. Section [5] outlines a novel approach to 
improving air interface user privacy in mobile telephony us¬ 
ing multiple IMSIs. Sections [6] and [7| provide descriptions 
of two proposed approaches to the use and management of 
multiple IMSIs in a USIM. An analysis of the proposed ap¬ 
proaches is presented in section[Sl Section[5]provides a brief 
discussion of related work. Finally, conclusions are drawn 
and possible directions for future work are considered in sec¬ 
tion [121 

2. BACKGROUND 

2.1 Mobile Systems 

In 3G systems a complete mobile phone is referred to as 
a User Equipment (UE), where the term encapsulates not 
only the mobile equipment (ME), i.e. the phone, but also 
the USIM within it [3], where the USIM takes the form of 
a cut-down smart card. The USIM embodies the relation¬ 
ship between the human user and the issuing home network, 
including the IMSI, the telephone number of the UE, and 
other user (subscriber) data. In particular the USIM holds 
a secret key shared with the issuing network, which forms 
the basis for all the air interface security features. 

The USIM data storage capabilities are specified in section 

10.1 of 3GPP TS 121 111 [11]. Information held within the 
USIM is stored in files, which are divided into the follow¬ 
ing categories: application dedicated files (ADEs), dedicated 
files (DFs) and elementary files (EEs), where EFs are fur¬ 
ther sub-divided into transparent EFs, linear fixed EFs and 
cyclic EFs depending on their storage requirements [I]. Files 
are composed of a header, which is internally managed by 
the USIM, and, optionally, a body part. The information 
in the header is related to the structure and attributes of 
the file, and may be retrieved from the USIM by sending it 
specific commands. The body part contains the data of the 
file. Most of the subscriber information is stored in EFs, 
which are the files we focus on in this paper. 


An IMSI is a fifteen numerical digit number. Of the fifteen 
digits, the first three form the mobile country code (MGC). 
The next two or three digits identify the network operator, 
and are known as the mobile network code (MNG). The 
length of the MNG, i.e. whether it contains two or three 
digits, is a national matter. The remaining nine or ten dig¬ 
its, known as the mobile subscriber identification number 
(MSIN), are administered by the relevant operator in accor¬ 
dance with the national policy [3 US]. IMSIs therefore have 
geographical significance, and their use is typically managed 


by the network operator in blocks. The combination of the 
MCC and the MNG can be used to uniquely identify the 
home network of the IMSI. The MSIN is used by the oper¬ 
ator to identify the subscriber for billing and other opera¬ 
tional purposes. Therefore, each IMSI uniquely identifies the 
mobile user, as well as the user’s home network and home 
country. The IMSI is stored in the USIM and is normally 
fixed. The elementary file EFjmsi contains the value of the 
IMSI. 

2.2 Proactive UICC 

Proactive UICC is a service operating across the USIM-ME 
interface that provides a mechanism for a USIM to initiate 
an action to be taken by the ME. It forms part of the USIM 
application toolkit. The 2G predecessor of the USIM, known 
as the SIM, supports a similar feature, known as proactive 
SIM, part of the SIM application toolkit. As described in the 
specification proactive UICG extends proactive SIM. 

ETSI TS 102 221 |12| specifies that the ME must communi¬ 
cate with the USIM using either the T=0 or T=1 protocol, 
specified in ISO/IEC 7816-3 [IS]- In both cases the ME is al¬ 
ways the master and thus initiates commands to the USIM; 
as a result there is no mechanism for the USIM to initiate 
communications with the ME. This limits the possibility of 
introducing new USIM features requiring the support of the 
ME, as the ME needs to know in advance what actions it 
should take. The proactive UICC service provides a mech¬ 
anism that allows the USIM to indicate to the ME, using 
a response to a ME-issued command, that it has some in¬ 
formation to send. The USIM achieves this by including a 
special status byte in the response application protocol data 
unit. The ME is then required to issue the FETCH com¬ 
mand to find out what the information is m- To avoid 
cross-phase compatibility problems, this service is only per¬ 
mitted to be used between a proactive UICC and a ME that 
supports the proactive UICC feature. The fact that an ME 
supports proactive UICC is revealed when it sends a TER¬ 
MINAL PROFILE command during UICC initialization. 


The USIM can make a variety of requests using the proac¬ 
tive UICC service. Examples include: requesting the ME to 
display USIM-provided text, notifying the ME of changes to 
EF(s), and providing local information from the ME to the 
USIM |14| . The commands of interest in this paper are RE¬ 
FRESH and DISPLAY TEXT. The REFRESH command 
requests the ME to carry out an initialisation procedure, 
or advises the ME that the contents of EF(s) have been 
changed. The command also makes it possible to restart 
the session by performing a reset. The DISPLAY TEXT 
command allows the UICC to request the ME to display 
text or an icon replacing anything else on its screen M- 

2.3 The AKA Protocol 

At the core of mobile telephony air interface security is a 
mutual authentication and authenticated key establishment 
protocol known as AKA (Authentication and Key Agree¬ 
ment). This is regularly performed between the visited net¬ 
work and the UE. The involved parties in AKA are the 
home network (the network that issued the USIM), the serv¬ 
ing network and the UE. The authentication center (AuC) 


of the home network generates authentication vectors (au¬ 
thentication data used by the serving network in AKA) and 
sends them to the serving network. 

The AKA protocol starts with the serving network sending 
an user authentication request to the UE. The UE checks 
the validity of this request (thereby authenticating the net¬ 
work), and then sends a user authentication response. The 
serving network checks this response to authenticate the UE. 
As a result, if successful, the UE and the network have au¬ 
thenticated each other, and at the same time they establish 
two shared secret keys. 


In order to participate in the protocol, the UE, in fact the 
USIM installed inside the UE, must possess two values: 

• a long term secret key K, known only to the USIM 
and to the USIM’s ‘home network’, and 

• a sequence number SQN, maintained by both the USIM 
and the home network. 

The key K never leaves the USIM, and the values of K and 
SQN are protected by the USIM’s physical security features. 


The 48-bit sequence number SQN enables the UE to ver¬ 
ify the ‘freshness’ of the user authentication request. More 
specifically, the request message contains two values: RAND 
and AUTN, where RAND is a 128-bit random number gen¬ 
erated by the home network, and the 128-bit A UTN consists 
of the concatenation of three values: SQN(BAK (48 bits), 
AMF (16 bits), and MAC (64 bits). The MAC is a Mes¬ 
sage Authentication Code (or tag) computed as a function of 
RAND, SQN, AMF, and the long term secret key K, using a 
MAC algorithm known as /I. The value AK is computed as 
a function of K and RAND, using a cipher mask generating 
function known as /5. The AK functions as a means of en¬ 
crypting SQN; this is necessary since, if sent in cleartext, the 
SQN value would potentially compromise user identity con¬ 
fidentiality, given that the value of SQN is USIM-specihc. 

On receipt of these two values, the USIM uses the received 
RAND, along with its stored value of A, to regenerate the 
value of AK, which it can then use to recover SQN. It next 
uses its stored key K, together with the received values of 
RAND, SQN, and AMF, in function /I to regenerate MAC; 
if the newly computed value agrees with the value received in 
A UTN then the first stage of authentication has succeeded. 
The USIM next checks that SQN is a ‘new’ value; if so it 
updates its stored SQN value and the network has been au¬ 
thenticated. 


If authentication succeeds, the USIM computes another mes¬ 
sage authentication code, called RES, from K and RAND 
using a distinct MAC function /2, and sends it to the net¬ 
work as part of the user authentication response. If this RES 
agrees with the value expected by the network then the UE 
is deemed authenticated. 


3. USER PRIVACY 

We start our consideration of user privacy by introducing 
the privacy-related terminology of relevance to this paper. 
Anonymity of a subject means that the subject is not iden¬ 
tifiable within a set of subjects known as the anonymity set 
m- Unlinkability of two or more items of interest (e.g. 
subjects, messages, actions) means that within the system 
an interested party cannot distinguish whether or not they 
are related m- Untraceability of an item of interest means 
that an interested party cannot determine whether or not it 
exists or is present. User anonymity, unlinkability and un¬ 
traceability are clearly all desirable properties from a user 
privacy perspective. 

In a mobile telephony context, a user identity can be the 
mobile number or the IMSI of a USIM, or the international 
mobile station equipment identity (IMEI) of an ME. Of 
these various identities, the IMSI is used to identify the sub¬ 
scriber for authentication, access provision and accounting 
purposes; limiting the degree to which its use compromises 
user privacy is the main focus of this paper. When a sub¬ 
scriber is roaming, i.e. accessing service from a network other 
than its home network, the IMSI is sent from the UE via the 
visited network to the home network. Since the IMSI is a 
permanent user identity, the air interface protocols are de¬ 
signed to minimise the number of circumstances in which it 
is sent across the air interface. 


Clearly, providing identity confidentiality in mobile telephony 
requires that the permanent user identity cannot be inter¬ 
cepted when sent across the radio access link. A similar 
requirement applies to the provision of user location confi¬ 
dentiality and user untraceability, which, like identity con¬ 
fidentiality, are identified as desirable features in the 3GPP 
security architecture [3]. A level of identity confidentiality is 
provided by use of the TMSI instead of the IMSI. However, 
as noted above, there are circumstances where a UE needs to 
send its IMSI across the air interface in cleartext. One such 
case is when a UE is switched on and wishes to connect to 
a new network, and hence will not have an assigned TMSI. 
Another case is where the serving network is unable to iden¬ 
tify the IMSI from the TMSI |15| . An active adversary can 
intentionally simulate one of these scenarios to force a UE 
to transfer its IMSI in cleartext. Moreover, several further 
scenarios have been identified [5l[l|27| in which use of the 
TMSI fails to protect user identity confidentiality. In the 
remainder of this paper, we propose a novel approach to im¬ 
proving user privacy in the air interface, which requires no 
modifications to the existing deployed mobile telecommuni¬ 
cations infrastructures, including the phones. Before doing 
so we present our threat model. 

4. THREAT MODEL 

The schemes we propose in this paper are designed to ad¬ 
dress real-life threats to user privacy in 3G networks. In 
particular we have already observed that there are circum¬ 
stances in which an opponent can cause a UE to send its 
IMSI across the network in plaintext. This is the threat we 
aim to mitigate, by reducing the impact of IMSI compro¬ 
mise. That is, although the possibility of IMSI compromise 
remains unchanged, the schemes we propose make the IMSI 


a short term identity, and hence we prevent the compromise 
of a long-term user identity. In doing so we must also ensure 
that two different IMSIs for the same UE are not linkable, 
at least via the network protocol. This issue is examined 
further in section EU 

In designing our schemes we make the underlying assump¬ 
tion that the AKA protocol is sound, and provides mutually 
authenticated key establishment. We also implicitly assume 
that the USIM and the network have not been compromised 
by other means. Of course, if these assumptions are false, 
then very serious threats exist to both user privacy and secu¬ 
rity. Since we assume that the AKA protocol is secure, and 
no changes are made to its operation, we do not need to re¬ 
examine its security for the schemes we discuss below. The 
main risk introduced by use of the multiple-IMSI schemes 
we propose is the possibility of loss of IMSI synchronisation 
between UE and home network, and this issue is addressed 
in section El 


It is important to note that two of the three schemes we 
describe rely on using the RAND sent as part of the AKA 
protocol as a means of signalling from the home network to 
the USIM. We observe that, from our assumption regarding 
the security of AKA, we can assume that this provides an 
authenticated channel with replay detection. This is funda¬ 
mental to the schemes presented in sections 16.21 and 171 


5. A PSEUDONYMITY APPROACH 

The capabilities of the USIM continue to evolve, allowing the 
possible storage of multiple IMSIs [24]. Whilst other authors 
have proposed to use this capability to allow the storage of 
multiple virtual USIMs on a single device, as discussed in 
section (9] we consider here the possible use of multiple IM¬ 
SIs for a single account to provide a form of pseudonymity 
on the air interface, even when it is necessary to send the 
IMSI in cleartext. The use of multiple IMSIs is described 
here using 3G terminology, but a precisely analogous ap¬ 
proach would apply equally to both GSM and LTE systems. 
However, while all the techniques for IMSI distribution spec¬ 
ified in sections [6] and [7| would also work for LTE, only the 
scheme described in section ED would work for GSM, since 
the other two schemes rely on UE authentication of the net¬ 
work which is not provided in GSM. 

At present, a USIM holds one IMSI with other relevant pa¬ 
rameters specific to the subscription and the network. We 
propose that a USIM and the home network support the use 
of varying IMSIs for a single user account, in such a way that 
no modification is required to the operation of any interme¬ 
diate entities, notably the visited (serving) network and the 
ME itself. This allows the provision of a more robust form 
of pseudonymity without making any changes to the air in¬ 
terface protocol. In this section we consider in greater detail 
how the change of IMSI can be made. 

A number of issues need to be addressed in order to make 
use of multiple IMSIs, as follows. 


• Transferring IMSIs. Clearly, before a USIM switches 
to a new IMSI, this value must be present both in 
the USIM and in the database of the home network. 
Moreover, new IMSIs must always be chosen by the 
home network to avoid the possibility of a single IMSI 
being assigned to two different USIMs. This requires 
a direct means of communication between the home 
network and the USIM (which must be transparent to 
the serving network and the ME, since our objective 
is to enable changing of an IMSI without making any 
changes to existing deployed equipments). In sections 
[6]and[7]we describe in detail two different strategies for 
transferring IMSIs from the home network to a USIM. 

• Initiating an IMSI change. Clearly the IMSI needs to 
be changed in such a way that both the home net¬ 
work and the USIM know at all times which IMSI is 
being used, and the home network always knows the 
correspondence between the IMSI being used by the 
USIM and the user account. An IMSI change can be 
triggered either by the USIM or by the home network, 
as we describe below. However, use of a new IMSI 
is always implemented by the USIM, since it is the 
appearance of a mobile device in a network using a 
particular IMSI which causes a request to be sent by 
the serving network for authentication information for 
use in the AKA protocol. That is, when the ME sends 
an IMSI to the serving network, it is forwarded to the 
home network. Once the home network sees the ‘new’ 
IMSI it knows that an IMSI change has occurred and 
can act accordingly. 

This requires that the home network knows that both 
the previously used IMSI and the ‘new’ IMSI belong 
to the same account. This will require some minor 
changes to the operation of the home network’s ac¬ 
count database, i.e. to allow more than one IMSI to 
point to a single account. However, this does not seem 
likely be a major problem in practice. 

• Triggering an IMSI changes. Whether the USIM or 
the home network is responsible for initiating a change 
of IMSI, logic needs to be implemented to cause such a 
change to take place. Regardless of whether the USIM 
or the home network makes the decision, logic needs to 
be in place in the USIM either to make the decision or 
to receive the instruction to make the change from the 
home network; for convenience we refer to this logic as 
an application, although this is not intended to con¬ 
strain how it is implemented. The decision-making 
logic could take account of external factors, includ¬ 
ing, for example, the elapsed time or the number of 
AKA interactions since the last change; indeed, if the 
ME included an appropriate user-facing application, 
then it might also be possible to allow user-initiated 
changes. Of course, if the home network is respon¬ 
sible for triggering the change of IMSI, then it needs 
a means of communicating its decision to the USIM 
that is transparent to the existing infrastructure, in¬ 
cluding the serving network and the ME. This issue is 
addressed in sections [6] and (T] 

• Rate of change of IMSI. The rate of change of IMSI 
will clearly be decided by the network which issues the 


USIM (and equips it with the IMSI-changing applica¬ 
tion). We observe in this context that section 4.2.2 of 
ETSI TS 131 102 |10| recommends that IMSI updates 
should not occur frequently. The rate of change of an 
IMSI could be determined by the customer contract 
with the issuing network; for example, a USIM which 
changes its IMSI frequently could cost more than a 
fixed-IMSI USIM (or one that only changes its IMSI 
occasionally), and could be marketed as part of a spe¬ 
cial ‘high-privacy’ service. 

• Implementing an IMSI change. A mechanism will be 
required for the USIM to indicate to the ME that the 
IMSI has changed. We propose that this should be 
achieved by the following steps. 

1. As noted in section [m the IMSI is contained 
in the elementary file EFimsi- When the USIM 
wishes to change the IMSI, it first updates this 
file accordingly. 

2. At the first opportunity, the USIM uses the proac¬ 
tive UICC status byte to indicate to the ME that 
it wishes to issue a command. 

3. When the ME responds with a FETCH com¬ 
mand, the USIM sends a REFRESH or a DIS¬ 
PLAY TEXT command to the ME, depending 
on the capabilities of the ME. 

4. The REFRESH command causes the ME to read 
the EFimsi hie, allowing it to discover the new 
IMSI. Alternatively, the DISPLAY TEXT com¬ 
mand causes the ME to display text instructing 
the user to restart the ME. 

5. On the next occasion the ME is required to send 
its IMSI to the serving network, it will send the 
new value. 

As noted above, the use of multiple IMSIs requires a di¬ 
rect and transparent means of communication between the 
home network and the USIM. We observe that the Unstruc¬ 
tured Supplementary Service Data (USSD) protocol appears 
at hrst sight to be a possible channel for such communica¬ 
tions. However, the protocol end points are the home net¬ 
work and the ME, rather than the USIM. As such, it could 
only be used for our purposes if the ME was aware of the 
multiple IMSI scheme, i.e. the ME would need to be mod- 
ihed — contradicting our design objectives. As a result we 
do not consider the use of USSD further here, although we 
note that it might be possible to deploy a smart phone appli¬ 
cation which could provide the necessary additional phone 
functionality, a possible avenue for future research. 

6. PREDEFINED MULTIPLE IMSIS 

Our hrst proposed means of deploying multiple IMSIs in¬ 
volves an issued USIM being pre-equipped with a number of 
IMSIs. All these IMSIs are associated with a single account 
in the home network’s account database. Initially, one of 
these IMSIs is stored in the Hie EFimsi- We propose below 
two different approaches to initiating a change of IMSI in 
this case. 


6.1 USIM-initiated IMSI change 

This is the simpler of the two approaches. We suppose that 
the USIM is equipped with an application that decides when 
to initiate an IMSI change. The application could make this 
decision on the basis of use of the USIM by the ME, e.g. the 
number of times the AKA protocol is performed. 


The new IMSI will clearly need to be selected from the pre¬ 
programmed list. How the list is used would be a matter for 
the issuing network. For example, the IMSIs could be used 
in cyclic order, or they could be used at random (or, more 
probably, pseudo-randomly). The USIM changes the IMSI 
to the ‘new’ IMSI using the procedure described in section 

m 

6.2 Network-initiated IMSI change 

In this case, the home network decides when to trigger an 
IMSI change. The home network will have a richer set of in¬ 
formation available to use to decide when to make an IMSI 
change than the USIM. For example, the home network 
could decide to change an IMSI whenever the USIM changes 
serving network, or after a Hxed number of calls. 

As discussed in section when the home network decides 
to trigger an IMSI change, it must, by some means, send an 
instruction to the USIM. We propose to use the AKA proto¬ 
col as the communications channel for this instruction. More 
specihcally, we propose using the challenge value {RAND) 
of AKA to carry the signal. The IMSI change procedure 
operates as follows (see also Figure [!}. 

1. When the logic in the home network decide that an 
IMSI change is necessary, a flag is set for the appro¬ 
priate user account in the AuC database of the home 
network. 

2. Whenever the AuC is required to generate authentica¬ 
tion vectors for use in the AKA protocol, it checks this 
Hag to see if an IMSI change signal is to be embedded 
in the RAND value. If so it resets the flag and follows 
the following steps (as shown in Figure [TJ a)). 

(a) The AuC uses the existing MAC function /fl to 
generate a 64-bit MAC on the subscriber’s cur¬ 
rent sequence number SQN using the subscriber’s 
long term cryptographic key K. We refer to this 
as the sequence-MAC or SMAC. 

(b) The AuC generates a 64-bit random number R 
using the same process as normally used to gen¬ 
erate 128-bit RAND values. 

(c) The AuC sets RAND to be the concatenation of 
the R and SMAC. 

If an IMSI change signal is not required, the AuC gen¬ 
erates RAND in the normal way. 

^For cryptographic cleanliness it should be verified that the 
data string input for this additional use of fl can never be 
the same as the data string input to fl for its other uses; 
alternatively, a slight variant of fl could be employed here. 





(a) Home Network 

Figure 1: IMSI change procedure for predefined multiple IMSIs 


3. The AuC follows the standard steps to generate the 
authentication vector from the RAND value, and sends 
the vector (including RAND) to the serving network. 

Whenever the USIM receives an authentication request, it 
follows the usual AKA steps. If the AKA procedure com¬ 
pletes successfully, the USIM checks the RAND in the fol¬ 
lowing way (as shown in Figure[T](b)). 

1. The USIM uses the received SQN and its stored long 
term key K to regenerate SMAC. 

2. It compares the computed SMAC with the appropriate 
part of RAND. 

3. If they do not agree then the USIM terminates the 
checking process. However, if they agree then the 
USIM performs the next step. 

4. The USIM selects a ‘new’ IMSI value from the stored 
list, and changes the IMSI accordingly using the pro¬ 
cedure described in section [3 


We next consider how the IMSI change process will work 
in practice. There are two cases to consider. If the home 
network is the same as the serving network then the home 
network could potentially force an instance of the AKA pro¬ 
tocol to occur at will, i.e. making the IMSI change happen 
almost immediately. However, if the serving network is dis¬ 
tinct from the home network, then the home network will 
only be able to send new authentication vectors when they 
are requested by the serving network. Moreover, the serv¬ 
ing network may wait for a while before using the supplied 
authentication vector in the AKA protocol. That is, in this 
case there may be a significant delay between the decision 
being made to change an IMSI and the signal being sent 
to the USIM. In either case the phone may actually be 
switched off or temporarily out of range of a base station, 
in which case there will inevitably be some delay. However, 
regardless of the length of the delay in the signal reaching 
the USIM (or even if the signal never reaches the USIM) 
there is no danger of loss of IMSI synchronisation between 
the USIM and the home network, since the home network 
will always retain the complete list of IMSIs allocated to the 
particular USIM. 


We observe that there is always the chance that a randomly 
chosen RAND will contain the ‘correct’ SMAC, leading to 
an unscheduled IMSI change by the USIM. However, the 
probability of this occurring is 2“®^, which is vanishingly 
small. In any case, the occurrence of such event would not 
have an adverse impact, since the home network would al¬ 
ways be aware of the link between the new IMSI and the 
particular USIM. 

Finally, an active interceptor could introduce its own RAND 
into the channel in an attempt to force an IMSI change. 
However, given that K is not compromised and fl has the 
properties required of a good MAC function, then no strat¬ 
egy better than generating a random RAND will be avail¬ 
able. Replays of old RAND values will be detected and 
rejected as a normal part of the AKA protocol (at least for 
3G and 4G networks, which enable the USIM to check the 
freshness of an authentication request). Finally, assuming 
the SMAC value is indistinguishable from a random value, 
a standard assumption for MAC functions, then an eaves¬ 
dropper will be unable to determine when an IMSI change 
is being requested. 

7. MODIFIABLE MULTIPLE IMSIS 

The second proposed means of deploying multiple IMSIs in¬ 
volves distributing new IMSI values from the home network 
to the USIM after its initial deployment, where the home 
network will choose each new IMSI from its pool of unused 
values. Such an approach clearly requires a means of com¬ 
municating from the home network directly to the USIM, 
and, analogously to the scheme proposed in section [6^ we 
describe how the AKA protocol, and specifically the RAND 
value, can be used for this purpose. 

Before describing the details of the IMSI transfer procedure, 
we describe some relatively minor changes which are re¬ 
quired to the operation of the home network in order to 
support the scheme. 


• The home network must maintain a pool of unused 
IMSIs, enabling the AuC to dynamically assign a new 
IMSI to an existing subscriber. 

• For each subscriber account in its database, the home 
network must maintain an IMSI-change flag indicating 


































whether an IMSI change is under way. The database 
must also hold up to two IMSIs for each subscriber; 
it will always hold the current IMSI (with status allo¬ 
cated) and, if the IMSI-change flag is set, it may also 
hold the new IMSI (with status in transit), where the 
possible status values for an IMSI are discussed below. 
If use of the new IMSI is observed then IMSI status 
changes are triggered (see below). 

• The home network must manage the use of IMSIs so 
that no IMSI is assigned to more than one subscriber 
at any one time. This can be achieved by maintaining 
the status of each IMSI as one of allocated, free, or in 
transit. The set of IMSIs with status free corresponds 
to the pool of available IMSIs referred to above. The 
status of an IMSI can be updated in the following ways. 

— When the home network selects an available IMSI 
from the pool to allocate to a USIM, the home 
network changes the status from free to in transit. 

— When the home network receives implicit acknowl¬ 
edgement (in the form of a request for authen¬ 
tication vectors for that IMSI from a network) 
of a successful IMSI change, the home network 
changes the status of the IMSI from in transit to 
allocated, and the status of the previously used 
IMSI for that subscriber from allocated to free. 
In addition, the current IMSI for the subscriber 
will be set equal to the new IMSI, the new IMSI 
will be set to null, and the IMSI-change flag will 
be reset. 

— A third case also needs to be considered, that is 
when an IMSI change instruction never reaches 
the USIM. If this case is not addressed then future 
IMSI changes for that USIM will be blocked. On 
the other hand, making a decision to abandon an 
IMSI change could be disastrous, i.e. if a USIM 
makes an IMSI change after the home network has 
terminated this change (and changed the status of 
the ‘new’ IMSI back to free), then the USIM could 
be rendered unusable. As a result we propose 
never to abandon an IMSI change, and instead to 
resend the new IMSI as many times as necessary 
until the change is accepted by the USIM. How 
this works should be clear from the description 
below. 

• If the home network is required to do so by its regula¬ 
tory environment, e.g. to support lawful interception, 
it can maintain a log of all the IMSIs assigned to a 
particular subscriber for however long is required. It 
is also likely to be necessary to retain this informa¬ 
tion for a period to enable processing of billing records 
received from visited networks. 

The details of the IMSI transfer procedure are as follows (see 
also Figure!^. 

1. When the logic in the home network decides that an 
IMSI transfer is necessary for a particular subscriber, 
it must set the IMSI-change flag for that subscriber. 
Observe that if an IMSI change is already under way 


then the flag will already be set; in this case the flag 
is left as it is. 

2. Whenever the AuC is required to generate authentica¬ 
tion vectors for use in the AKA protocol, it checks this 
flag to see if an IMSI transfer signal and a new IMSI are 
to be embedded in the RAND value. If so it follows the 
following steps (as shown in Figure [2K a)). Note that 
this means that, once an IMSI change has been ini¬ 
tiated, the new IMSI will be embedded in all RAND 
values until evidence of the successful changeover by 
the USIM has been observed. 

(a) The AuC uses the MAC function /I to gener¬ 
ate a 64-bit MAC on the subscriber’s current se¬ 
quence number SQN using the subscriber’s long 
term cryptographic key K. The generated MAC 
is referred as SMAC. 

(b) The AuC generates a 48-bit encryption key EK 
using the key generation function /5. The func¬ 
tion takes SQN as the data input and K as the 
key input. Note that observations regarding cryp¬ 
tographic cleanliness and the use here of functions 
/I and /5, analogous to those given in section lU^ 
step 2(a), apply here. 

(c) If the new IMSI field in the home network database 
entry for this subscriber is non-null then a new 
IMSI has already been assigned, and it is not nec¬ 
essary to choose another new value. Otherwise 
a new IMSI is selected from the pool of unused 
IMSIs; the status of this IMSI is changed from 
free to in transit and the new IMSI field in the 
database is given the chosen value. We assume 
that the MCC and MNC of the IMSI are known 
to the USIM (since they are fixed for this net¬ 
work operator) and hence only the 9- or 10-digit 
MSIN needs to be sent embedded in RAND. The 
MSIN is encoded as a 36- or 40-bit value using 
binary coded decimal, the ‘standard’ way of en¬ 
coding IMSIs, and the result is padded to 48 bits 
by an agreed padding scheme. 

(d) The 48-bit MSIN block is XORed with the en¬ 
cryption key EK, and we refer to the result as 
the concealed MSIN. 

(e) The AuC generates a 16-bit random number R 
using the same process as normally used to gen¬ 
erate 128-bit RAND values. 

(f) The AuC sets RAND to be the concatenation of 
the concealed MSIN, R and SMAC. 

If an IMSI transfer is not required, the AuC generates 
RAND in the normal way. 

3. The AuC follows the standard steps to generate the 
authentication vector from the RAND value, and sends 
the vector (including RAND) to the serving network. 

On receipt of an authentication request, the USIM proceeds 
using the standard AKA procedure. After successful com¬ 
pletion of the AKA protocol, the USIM checks whether the 
challenge value contains an embedded IMSI in the following 
way (as shown in Figure [2](b)). 




Figure 2: IMSI change procedure for modifiable multiple IMSIs 


1. The USIM uses the received SQN and its stored long 
term key K to regenerate SMAC. 

2. It compares the computed SMAC with the appropriate 
part of RAND. 

3. If they do not agree then the USIM terminates the 
checking process. However, if they agree then the 
USIM performs the following steps. 

(a) The USIM retrieves the concealed MSIN from 

RAND. 

(b) The USIM regenerates the encryption key EK us¬ 
ing /5 with the value of SQN retrieved during the 
AKA processing and its long-term stored key K 
as inputs. 

(c) The EK is XORed with the concealed MSIN to 
recover the cleartext encoded MSIN. 

(d) The USIM generates the new IMSI by prefixing 
the decoded MSIN with the MCC and MNC. 

(e) The USIM checks whether the new IMSI is the 
same as the value it is using already; this is es¬ 
sential since it may receive the change instruction 
more than once. If they are the same it does noth¬ 
ing. If they are different it updates its IMSI using 
the procedure described in section 

To reduce signalling costs, it appears to be standard practice 
for the AuC to generate a small set of authentication vectors 
for provision to a serving network. If the procedure specified 
above is followed to generate this set of vectors, and an IMSI 
change is scheduled for the subscriber, then all the RAND 
values in the set will contain an embedded concealed MSIN. 
Whilst this will cause minimal additional overhead for the 
USIM, since RAND values are always checked for an embed¬ 
ded SMAC value, it will have the benefit of maximising the 
chance that the IMSI change will be performed by the USIM. 

As discussed in section Ejl there may be a significant delay 
in the IMSI change signal embedded in the RAND reaching 
the USIM. However, this will not affect IMSI synchronisa¬ 
tion between the home network and the USIM since the 
home network will not update the current IMSI entry in the 


subscriber database until it receives a request for authenti¬ 
cation vectors from a visited network using this new IMSI. 
As discussed above, once a new IMSI has been assigned to 
a subscriber (with the in transit status), every RAND gen¬ 
erated for that USIM will contain the embedded IMSI value 
until the success of the change has been observed. 

Finally, as discussed in section [6^ there is the chance that 
a randomly chosen RAND could contain a ‘correct’ SMAC, 
triggering an unauthorised IMSI change. However, the prob¬ 
ability of such an event is vanishingly small, and certainly 
orders of magnitude smaller than the probability of a USIM 
failure. We therefore do not consider it further here. 

8. ANALYSIS 

The above proposals raise privacy and availability issues, 
which we now discuss. 

8.1 User privacy 

The use of multiple IMSIs does not provide a complete so¬ 
lution to user identity confidentiality. While it is in use the 
IMSI still functions as a pseudonym, potentially enabling 
the interactions of a single phone to be tracked for a period. 
Of course, the more frequently IMSIs are changed the less 
the impact of possible tracking, but frequent IMSI changes 
have an overhead in terms of database management. The 
use of a predefined set of IMSIs further restricts the degree 
to which user identity confidentiality is protected. In this 
case, over a period of time it might be possible for an eaves¬ 
dropper to link at least some of the fixed IMSIs. 


The design of the proposed schemes ensures that an eaves¬ 
dropper will not be able to infer any confidential information 
from the value of RAND. As discussed in sections l6.2l andr7l 
in schemes where the RAND is used to signal to the USIM, 
the RAND is constructed in such a way that it is indistin¬ 
guishable from a truly random value; this is based on the 
assumption that a MAC generated fl and a data string en¬ 
crypted using the output from /5 are indistinguishable from 
random data. Moreover, in the scheme described in section 
[7| where the IMSI is sent embedded in RAND, the IMSI (ac¬ 
tually the MSIN) is encrypted to prevent an eavesdropper 
observing it. 

































































Overall the IMSI-changing proposal can be seen as allowing 
a trade-off between user privacy and the cost of implement¬ 
ing frequent IMSI changes. 

8.2 IMSI synchronisation 

If, in the modifiable multiple IMSIs case, an active attacker 
is able to persuade the USIM to change its IMSI to an unau¬ 
thorised value, then the USIM (and the UE) will cease to 
be able to access the network. It is therefore essential that 
robust cryptographic (and other) means are used to guaran¬ 
tee the correctness and timeliness of the new IMSI. 


In the two variants of the predefined IMSIs scheme described 
in section [6] loss of synchronisation cannot arise, as even if 
the USIM is persuaded to make an unauthorised change the 
new IMSI will be known to the home network. In any event, 
as argued in section 16)^ the probability of such an event is 
vanishingly small. 

Loss of synchronisation appears to be a more significant 
threat in the case where new IMSIs are sent embedded in 
the RAND value, as in the scheme described in section [T] 
However, as discussed there, for similar arguments to those 
given in section |621 the probability of a random RAND giv¬ 
ing a correct SMAC is negligible. Also, malicious changes to 
a valid RAND, e.g. involving changing the encrypted MSIN 
whilst leaving the SMAC unchanged, will be detected by 
the AKA network authentication process. 

9. RELATED WORK 

To the best of the authors’ knowledge, no user privacy en¬ 
hancing scheme for mobile telephony has previously been 
proposed that does not require changes to the existing net¬ 
works. While other authors observe that significant changes 
to widely deployed infrastructure are unlikely to be feasible 
[aiiT], realistic and practical proposals have not been made. 
Choudhury et al. [6] have proposed a scheme to improve user 
identity confidentiality in the LTE network. Their scheme 
involves significant changes to the air interface protocol. 
They propose the use of a frequently changing dynamic mo¬ 
bile subscriber identity (DMSI) instead of the IMSI across 
the air interface. The DMSIs are managed by the home net¬ 
work and the USIM. However, the use of the DMSI imposes 
changes in the protocol messages, mobile equipment, and the 
serving network. Kpien m has recently proposed a privacy 
enhanced mutual authentication scheme for LTE. Although 
the author claims to use existing signalling mechanisms, the 
author introduces identity based encryption to encrypt the 
IMSI when sent across the air interface. 


A number of schemes involving the use of multiple IMSIs 
with a single USIM have been proposed. Marsden and Mar¬ 
shall m describe a scheme to use multiple IMSIs for mul¬ 
tiple networks with a single USIM. Their scheme involves 
the use of an update server to provide a suitable IMSI as 
and when it is required. Tagg and Campbell |24| propose 
a similar approach involving multiple virtual USIMs on a 
single device. In both cases the objective is to avoid roam¬ 


ing charges by dynamically switching network provider. The 
focus of their work is thus very different to the schemes de¬ 
scribed above; they also do not provide a means of transfer¬ 
ring new IMSIs transparently to a USIM. 

Dupre [S] presents a process to control a subscriber iden¬ 
tity module (SIM) for mobile phone systems. He provides 
generic guidance regarding the transmission of control infor¬ 
mation from the network to the SIM. The schemes described 
in this paper extends Dupre’s idea in a more concrete way. 

10. CONCLUSIONS 

In this paper we propose two approaches to using multiple 
IMSIs for a mobile telephony subscriber. The goal of these 
proposals is to improve user privacy by reducing the impact 
of IMSI disclosure on the air interface. The approaches do 
not require any changes to the existing deployed network in¬ 
frastructures, air interface protocols or mobile devices. The 
overhead introduced is modest and should be feasible to 
manage in real-world networks. One major advantage is 
that the proposed schemes could be deployed immediately 
since they are completely transparent to the existing mobile 
telephony infrastructure. 

The proposed schemes provide a form of pseudonymity on 
the air interface, even when it is necessary to send the IMSI 
in cleartext. The schemes reduce the impact of user pri¬ 
vacy threats arising from IMSI capturing. In doing so they 
improve user location confidentiality, because the location 
update message involves sending the cleartext user identity 
(i.e. the IMSI or TMSI) across the air interface. 

There is ample scope for future work. Evaluating the pro¬ 
posed schemes by simulation is the current priority. Future 
work could concentrate on setting reliable rules for trigger¬ 
ing an IMSI change. 
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